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(57) ABSTRACT 

A communications apparatus for enabling communications 
among networks, buses, devices and other subsystems hav- 
ing different communication requirements is provided. The 
communications apparatus offers an open architecture for 
interoperability among diverse subsystems. The communi- 
cations apparatus is particularly applicable in a vehicle. In 
one embodiment, a portal apparatus located remote from the 
vehicle facilitates communications with the communications 
apparatus, particularly where the vehicle is part of a vehicle 
fleet. The communications apparatus includes a common 
module that has at least one protocol by which disparate 
subsystems can communicate with each other. One or more 
managers can be defined as being part of the common 
module. The disparate subsystem managers provide the 
necessary interfacing to enable the disparate subsystems to 
communicate between and among each other using the 
common module. Each such manager has dedicated func- 
tionalities to facilitate communications. Managers associ- 
ated with the common module may include managers for use 
in configuration and diagnostic tasks, encryption/decryption, 
comprcssion/dc -compression, controlling data flow, security 
regulation, and selecting an acceptable link for outside 
communications. The common module also includes a base 
manager for registering disparate subsystem managers 
including associating a name with each of them. 

30 Claims, 3 Drawing Sheets 
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COMMUNICATIONS INVOLVING 
DISPARATE PROTOCOL NETWORK/BUS 
AND DEVICE SUBSYSTEMS 

This application is related to and claims priority from 
Provisional Patent Application No. 60/139,820 filed Jun. 17, 
1999. 

FIELD OF THE INVENTION 

The present invention relates to enabling communications 
between or among different operably interconnected devices 
and, in particular, to providing communications internally 
and externally of a vehicle, involving disparate subsystems 
using a common module and appropriate managers. 

BACKGROUND OF THE INVENTION 

Communications hardware and associated operations in 
different makes and models of vehicles continue to expand. 
There are currently, however, no standards or common 
procedures by which each of a number of disparate hardware 
devices can be opcratively connected together for common 
purposes. This lack of effective connectivity inhibits desired 
communications between and among disparate networks, 
buses, devices and any other subsystems that might be found 
in a vehicle. This connectivity deficiency also negatively 
impacts the ability of one or more remote stations to 
communicate with such nodes in the vehicle. 

Information transfers involving a remote station with 
hardware subsystems located in a vehicle have been 
enhanced with the availability of the Internet and wireless 
systems. A computer or other intelligent device located in 
the vehicle can communicate with one or more remote 
stations using, the Internet and wireless technology. U.S. 
Pal. No. 5,732,074 issued Mar. 24, 1998 entitled "Mobile 
Portable Wireless Communication System", which is 
assigned to the assignee of the present application, describes 
a system by which a network in the vehicle including a 
number of devices associated with the network can send and 
receive information relative to the Internet. 

With respect to multiple vehicle disparate subsystems in 
a vehicle, il is desirable to further facilitate communications 
both within and outside the vehicle, Iliis can be effectively 
accomplished by an open architecture that can be respon- 
sible for enabling communications among a plethora of 
present and potential subsystems for use in a vehicle. Such 
a communications apparatus must be able to handle different 
communications requirements and facilitate interconnection 
of the disparate subsystems. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a communica- 
tions apparatus is provided to enable information and data 
traasfcrs between or among disparate subsystems. In an 
exemplary embodiment, the communications apparatus is 
contained within a vehicle having a number of disparate 
subsystems. The disparate subsystems include protocol 
based units and close-ended devices. The protocol based 
units can include networks and buses having associated 
components or peripherals thai arc interconnected. The 
close -ended devices arc referred to herein as devices that do 
not have International. Standards Organization (ISO) net- 
work layering and typically constitute a terminating com- 
munication node in the context of data flow ending or 
originating from such a device, and not typically acting as a 
link or pass through device for information or data transfers. 
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An example of such a close-ended device might be a global 
positioning system (GPS) that is useful in providing vehicle 
location information or a hardware device, such as a vehicle 
sensor from which data can be obtained for a particular 
5 vehicle component to which the sensor is operably con- 
nected 

In addition to the GPS, disparate subsystems may include 
an Internet protocol (IP) stack comprised of a number of 
network layers that arc commonly involved in transfers 

10 using the Internet, a controller area network (CAN) found in 
at least some vehicles and which includes a bus along which 
a number of vehicle elements, communicate for supplying 
information concerning such elements. The disparate sub- 
systems can also include an intelligent transportation system 

]5 data bus (IDB) and/or an onboard diagnostics (OBD) that 
arc involved with monitoring and providing information 
related to vehicle components. Voice recognition (VR) tech- 
nology and text-to-speech (TTS) technology can also be part 
of the group of disparate subsystems and which are involved 

20 in facilitating speech control and response communications 
in the vehicle. Other disparate subsystems may include an 
analog/digital converter (ADC), a standard serial bus, a 
universal serial bus (USB), a user datagram packet/Internet 
protocol stack and a cellphone, as well as one or more other 

25 customer proprietary devices. 

In conjunction with enabling communications between 
and among the disparate subsystems, as well as communi- 
cations outside the vehicle, the communications apparatus 
includes a common module and a number of disparate 

3Q subsystem managers. The common module is defined as 
being comprised of a number of 'common module managers, 
which may include one or more of the following: a base 
manager for handling registration and de-registration of 
disparate subsystem managers, as well as other components 

35 or component proccssccs that perform communication tasks; 
a configuration manager for use in downloading 
applications, configuring routing tables, reviewing error logs 
and other assigned tasks; a diagnostics manager for collect- 
ing and relaying diagnostic data; a security manager for use 

40 in, among other things, monitoring external applications 
attempting to connect to the communications apparatus for 
security purposes; a flow manager having the ability, to 
interconnect children (child processes) of managers in order 
to perform operations on data passing through (hem; 

45 compression/decompression managers involved with com- 
pressing and de -compressing data being communicated; and 
cncryption/de-cncryplion managers for encrypting/dc- 
encrypling data, as well as user-defined services, that can 
process, filter or otherwise act on available data. 

50 I'hc disparate subsystem managers can communicate with 
each other involving the common module functionalities 
using at least one common protocol. In a preferred 
embodiment, two communication protocots arc available. 
These arc identified as a bus applications programming 

55 interface (API) and a stream API. The bus communication is 
useful in applications in which a number of independent 
components are involved in the communication, while, 
stream communication is useful for uastructured stream data 
between two components. 

60 With respect to the number of disparate subsystem 
managers, a dedicated one disparate subsystem manager is 
defined as communicating with a particular disparate sub- 
system. Accordingly, the number of disparate subsystem 
managers is equal to at least the number of disparate 

65 subsystems. Por example, a TCP/IP stack operably commu- 
nicates with a TCP/IP manager in order to participate in the 
functionalities and features associated with the communica- 
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tions apparatus. Each disparate subsystem manager provides 
functions that are common, namely: providing a native 
interface to the specific disparate subsystem with which it 
communicates* providing an interface to the common 
module, and performing a number of management functions. 5 
Conversely, because of the dissimilarities among the dispar- 
ate subsystems, many of the disparate subsystem managers 
have different software capabilities that arc unique to the 
particular disparate subsystem for which it has responsibil- 
ity. 10 

With respect to the interoperability among the disparate 
subsystems and the communications apparatus, an exem- 
plary operation is next described. A request for data or other 
information might originate from a source or site external to 
a vehicle having a communications apparatus. This request 15 
for information is communicated wirelessly using the Inter- 
net and its TCP/IP communication protocol and in which at 
least the vehicle has an Internet address, although compo- 
nents in the vehicle may also have separate Internet 
addresses. Wireless technology in the vehicle receives this 20 
Internet communication and it is routed or received by the 
TCP/IP disparate subsystem or protocol stack. The request 
for information is handled by the TCP/IP manager that is in 
direct communication with the TCP/IP disparate subsystem. 
Based on its recognition of the contents of the request for 25 
information, such as a configuration packet, the TCP/IP 
manager creates a first child process for establishing a 
stream API (application programmer's interface) for trans- 
ferring the requested information in stream form. In one 
embodiment, from the contents of the request, fox 30 
information, the TCP/IP manager is involved with at least 
some, if not all, of the request to a second manager that will 
be involved in obtaining the requested information. By way 
of example, the second manager might be the GPS manager, 
where the requested information includes NMEA data from 35 
a GPS disparate subsystem. In such a case, the informations 
related to the request received by the GPS manager is 
utili/.ed by it to manage or otherwise control the obtaining of 
data from the G1*S subsystem. In that regard, a second child 
process associated with obtaining the data from the GPS 40 
subsystem by a stream API is created. The second child 
process cooperates with the first child process to transmit the 
requested information from the GPS subsystem to the 
requesting source external to the vehicle. As part of creating 
each child process, the common module also is involved, 45 
through its base manager, in the registration of the dynami- 
cally created first and second child processees. When the 
request for information is satisfied, such child processees 
can he dc- registered using the base manager. Utilization of 
such child processees enables the managers to function with 50 
multiple requests that arc simultaneously satisfied or have 
overlapping needs for the same services using the same 
managers. The child processees may be spawned through the 
responsibility or management of other managers, such as the 
flow manager. Additionally, services associated with the 55 
obtaining of the data might be employed including com- 
pression of the obtained information and encryption thereof, 
as well as reliance on (he security manager to insure that the 
request for information has authorized access to the com- 
munications apparatus. 60 

In one embodiment, data gathering and other communi- 
cations are facilitated involving a fleet of vehicles, with each 
having an embedded communications apparatus. Instead of 
the owner/operator of the vehicle fleet directly accessing 
each of communications apparatuses in the vehicles of its g5 
fleet, a portal apparatus acts as a communications link 
between vehicle Meets and the fleet managing subsystem. 
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The portal apparatus facilitates downloading of software 
configurations and updates to each communications appa- 
ratus in the vehicles of the particular fleet, as well as 
facilitating the obtaining of vehicle operational data and 
other information including diagnostic data and status infor- 
mation including fault-related data. 

Based on the foregoing summary, a number of salient 
aspects of the present invention are readily identified. Trans- 
fers of information including data relative to different 
devices, buses and/or networks are substantially seamlessly 
achieved. Such transfers can be accomplished among these 
different subsystems without requiring that they be 
modified, thereby achieving a "plug and play" result. 'ITie 
disparate subsystems include protocol dependent compo- 
nents as well as close-ended devices at which data flow 
originates or is terminated, such as a GPS. Consequently, the 
communications apparatus of the present invention handles 
communications among devices that arc not characterized 
by ISO network layering. The disparate subsystems com- 
municate with each other using a common communications 
protocol involving a common module. Communications can 
occur involving the common module, both externally and 
internally of a vehicle. Such communication transfers can 
include: data logging, application program downloading, 
vehicle component or sensor monitoring and vehicle loca- 
tion information. In one embodiment, management of fleet 
vehicles is augmented by a portal apparatus located inter- 
mediate a number of communications apparatuses embed- 
ded in licet vehicles and fleet management subsystems. 

Additional advantages of the present invention will 
become readily apparent from the following discussion, 
particularly when taken together with the accompanying 
drawings 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 Is a block diagram, of the present invention 
illustrating the common module, disparate subsystems and 
disparate subsystem managers that interface between them; 
and 

FIG. 2 is a flow diagram related to exemplary communi- 
cations among disparate subsystems involving the commu- 
nications apparatus; and 

FIG. 3 is a block diagram illustrating a portal apparatus 
for use with vehicle fleet subsystems. 

DETAILED DESCRIPHON 

With reference to FIG. 1, a system is illustrated for 
enabling communications among disparate technologies. 
Although the system has particular application in a vehicle 
and will be described in the context of a vehicle application, 
it may be beneficial in other environments, such as manu- 
facturing facilities or other industrial complexes, offices and 
homes. 

The system includes a plurality of disparate subsystems 
20 and a communications apparatus 22. The disparate sub- 
systems 20 in a vehicle can include one or more of the 
following components: Internet protocol (IP) slacks 24; a 
global positioning system (GPS) 26; an intelligent transpor- 
tation system data bus (IDB) 28; an onboard diagnostics 
(OBD-II) 32; a controller area network (CAN) 36; a uni- 
versal serial bus (USB) 40; a standard serial bus 44; an 
analog/digital converter (ADC) 48; browser technology 52; 
voice recognition (VR) technology 56; lexl-to-speech (VVS) 
technology 60; a cellphone 64; user datagram packets/ 
Internet protocol slack(s) (UDP/IP), one or more custom or 
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proprietary units or components, as well as any other pres- 
ently or later devised subsystem that may be useful in a 
vehicle or another environment in which the system is 
operating. 

The disparate subsystems 20 are usually characterized by 
the differences in their interfaces including how they com- 
municate with other components. For example, an IP stack 
disparate subsystem 24 is characterized by International 
Standards Organization (ISO) network layering including a 
socket interface at the higher layer. In contrast, the OBD 
disparate subsystem 32 docs not follow the ISO network 
layering but could be characterized as a single layer dispar- 
ate subsystem having different interface requirements in 
order to properly communicate with it. 

With regard to identifying these disparate subsystems 20, 
the IP stack(s) 24 includc(s) a number of network layers 
typically involved in transmissions or information transfers 
over the Internet. The GPS 26 provides vehicle location 
related information, such as longitude, latitude, altitude. The 
OBD-II 32 is available in at least certain vehicles for use in 
providing engine related information, such as engine speed, 
pressure of certain components, etc., using sensors that may 
be useful in diagnosing-vehicle engine faults. The I OB 28 is 
a relatively new standard bus found in vehicles that has a 
number of vehicle elements that send/receive data or other 
vehicle-related information, such as fuel management or 
other vehicle device data, using a protocol analogous to 
TCP/IP. These vehicle elements can include vehicle 
windows, doors, air bags, lights, etc. The CAN 36 is another 
communications network within the vehicle for providing 
information from vehicle elements, such as automotive 
electronics including engine sensors, lamps, electric 
windows, etc. 'I*he USB 40 is a PC centric network that 
includes a bus for enabling communications among PC 
hardware, e.g., mouse, keyboard, printer, memory. The 
standard serial bus 44 accommodates information transfers 
from/to and among devices or components that are not 
presently known or not specific (e.g., unlike RS232, RS485 
compatible devices). The ADC 48 can be used to output 
necessary digital signals for providing useful information 
from devices connected thereto such as automotive elec- 
tronic elements that may be separate from and not associated 
with a particular bus. ITie VR technology 56 enables the 
vehicle driver or passenger to provide commands or other 
information verbally to achieve desired results including 
obtaining information. Ihc ITS technology, 60 provides the 
user or operator with a verbal output that can be readily 
heard. The browser technology 52 can access and provide 
desired information, particularly in combination with the 
VR and PI'S technologies, and is dependent on an Internet 
related external connection to satisfy the web-based request. 
ITie cellphone 64 is a useful communications tool in 
sending/receiving analog voice or digital data. 

A number of the disparate subsystems 20 are electrically 
connected to one or more nodes 80 that arc associated with 
a particular sender and/or receiver of the data/information in 
association with or part of the disparate subsystems 20. 
Representative of the nodes 80 arc nodes HQa-&Qg. The 
nodcl HOa can include an external application (hat is located 
outside of the vehicle and is wirclcssly connected to the 
disparate subsystem IP stack 24. By way of example, an 
application running on a computer station remote from a 
vehicle may receive vehicle data that it processes for pro- 
viding a desired report. Ilie nodc2 HOb may be defined as 
including one or more vehicle elements connected to the 
disparate subsystem 1DB 28. I Tie node3 80c may also be 
characterized as one or more vehicle elements associated 
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with vehicle engine functions that are connected to the OBD 
32. The oodc4 SOd may define a number of vehicle devices 
connected to the CAN 36. The node5 80e may also comprise 
a number of nodes, with each node associated with different 
s PC centric hardware and/or software in communication with 
the bus of the USB 40. The nodc6 80/ can also comprise or 
define a number of nodes, with each communicating with at 
least one component in the vehicle and with all of them 
electrically connected to the standard serial bus 44. The 

10 node7 80g can include one or more separate nodes commu- 
nicating with such vehicle components as sensors or other 
elements that may not be part of a particular vehicle network 
or bus and which require the ADC 48 for providing the 
necessary digital signal acceptable to the communications 

] 5 apparatus 24. The nodeS 80/t can include applications that 
communicate using the UDP protocol. 

In conjunction with enabling communications between 
and among each of the disparate subsystems 20 including, 
where applicable, their associated one or more nodes, the 

20 communications apparatus 22 can be defined as including a 
common module or interface 90 and a plurality of disparate 
subsystem managers 100. Generally, among the plurality of 
disparate subsystem managers 100, each disparate sub- 
system 20 is in communication with a different, specific one 

2s manager of the plurality of managers 100. In the illustrated 
embodiment, there are disparate subsystem managers 
110-154 in direct communication with disparate subsystems 
24-68, respectively. Each of the disparate subsystem man- 
agers 100 has common rcspoasibilities or functions. Ilicsc 

3u functions include: (1) providing a native interface to the 
specific disparate subsystem 20 with which it communi- 
cates; (2) providing an interface to the common module 90; 
and (3) performing a number of management functioas. 
Although having similarities, each manager 100 has differ- 

35 cnt software for handling the native interface since the 
disparate subsystems 20 usually have different requirements. 
For each disparate subsystem 20, the management functions 
can include: initiating and responding to messages relative 
to other disparate subsystem managers 100 for the purpose 

40 of providing desired communications including those 
involving the transfer of data or other information between 
or among them; and creating connections or links between 
other disparate subsystem managers 20 that result in a 
communications path using a selected common communi- 
st 5 cations protocol associated with the common module 90. In 
that regard, the common module 90, in one embodiment, can 
include two communication protocols for selection. A first 
communication protocol essentially involves use of request 
and response messaging, while the second common com- 

50 munications protocol essentially involves unstructured data 
transfer. 

The common module 90 has a number of functions in 
operating with the disparate subsystem managers 100 
including a registration procedure by which disparate sub- 

55 systems 20 and other components or component processees 
arc registered by the common module 90. As part of the 
registration procedure, a name or identifier is assigned to 
each such registered component and a message queue is 
established for each such component. As an example of a 

60 component process being registered, other than a disparate 
subsystem manager 100, once a connection is established for 
communication purposes between two disparate subsystem 
managers 100 that are connected to the common module 90, 
such a component process indicative of this connection is 

OS registered and such component process is assigned a 
dynamic name. The dynamic name is discontinued or 
dc-reglstcrcd upon completion of the particular component 
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process, such as completion of a data transfer that involves 
a connection between two disparate subsystem managers 
100. 

With respect to registration, the common module 90 
includes a base manager 170 that can be a software module 
for handling the registration and de-regislralion of disparate 
subsystem managers 100 and other components or compo- 
nent processees performing tasks or involved with commu- 
nications using the common module 90. The common mod- 
ule 90 may also have a configuration manager 180 as part 
thereof. The configuration manager 180 can be a web-based 
configuration tool that operates using hypertext transport 
protocol (HTTP). The configuration manager 180 utilizes a 
browser interface for configuration, i.e. downloading 
applications, configuring routing tables, reviewing error logs 
and other assigned tasks. Because of HTIP usage, users can 
configure via a wireless modem connection, through the 
local Ethernet port or through an available RS232 connec- 
tion using a suitable protocol, such as SLIP or PPP Imple- 
mentation of WTP provides a way to perform remote 
debugging as well as perform diagnostics and/or other 
services. 

Other managers that are part of the core platform asso- 
ciated with the common module 90 include a diagnostics 
manager 182, a security manager 184, a link selection 
manager 188, a flow manager 192 and a modem scripting 
manager 196. The diagnostics manager 182 is involved with 
obtaining and managing diagnostics information. The secu- 
rity manager 184. oversees managers 100 characterized by 
their use of particular protocols in communicating with their 
connected or associated disparate subsystem 20, as well as 
being characterized as being connected to disparate sub- 
systems 20 that are not close -ended, i.e., are not disparate 
subsystems 20 where data or other information flow termi- 
nates or originates, such as a GPS disparate subsystem 26. 
In overseeing such managers 100, the security manager 184 
monitors the connections made from sources outside the 
environment of the communications apparatus 22, such as 
external to a vehicle having the communications apparatus 
22. 'llic key security feature to be realized relates to moni- 
toring external applications attempting to connect to the 
communications apparatus 22. llic link selection manager 
188 functions to provide an acceptable network link for 
transmitting and/or receiving information wirelcssly relative 
to the vehicle. The How manager 192 provides the ability to 
string managers together to perform, operations on the data 
llowing through them. The flow manager 192 mediates 
between an application and available services by setting up 
a communications pipe that can contain one or more ser- 
vices. 'Itie pipe exists between the application and the 
intended recipient of data, without the application having 
any knowledge that the data Ls being modified through the 
process. As an example, the communications apparatus 24 
can be considered as a data flow machine in which data 
flows through a network of data processors that perform 
some action on the data. These actions are negotiated before 
hand by the mediator such that there is no delay in process- 
ing the data to be moved to air external site. The flow 
manager 192 can mediate a managed flow to a physical link. 
Once service agents arc selected and the flow is established, 
the data flows through the architecture and through each of 
the selected service agents. In one example, the data is first 
compressed and then encrypted prior to being exported out 
of the unit via the selected physical link. Conversely, data 
originating from an external source can be decrypted and 
decompressed after being imported to an internal process 
which allows for bi-directional functionality that is depen- 
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dent on the direction of flow of the data. The modem 
scripting manager 196 is responsible for initializing connec- 
tions through available modems through a standard setup 
package. 

s In addition to such identified managers involved in the 
operation of the common module 90, service providing 
managers can also be included, such as a compression 
service manager 210 and an encryption service manager 
214. The compression service manager 210 provides a 

10 service of compressing a stream of data passed from another 
component, such as through a stream connection. The com- 
pression service manager 210 provides the capability to pass 
its data to another component, typically different from the 
source application, to support the data flow architecture. The 
encryption service manager 214 provides a service of 
encrypting a stream of data passed from another component, 
such as through a stream connection. The encryption service 
manager 214 provides the capability to pass its data to 
another component, that is typically different from the 
source application, in order to support the data flow archi- 
tecture. 

The common module 90 may also be designed to have the 
ability to execute user applications that arc in direct com- 
munication therewith. The configuration manager 180 can 

25 provide the ability to load user applications 220 (e.g. 220a, 
. . . 220/i) into a user applications module in communication 
with the common module 90 and update necessary initial- 
ization files to support their execution when the system is 
booted up. Such user applications 220 will be provided with 

3(J the ability to register with the common module 90 and then 
communicate freely with the operating system, such as 
RTOS (real time operating system) that constitutes the 
operating system for the communications apparatus 22, 
together with the disparate subsystem managers 100 to 

35 satisfy their requirements. The common module 90 also 
includes a processing subsystem including a processing core 
that can be a Power PC. The processing subsystem can also 
include RAM (random access memory) and mutable flash 
storage, llic flash storage can be split into a compressed 

4f) kernel image and a mutable flash file system. 

The combination of the common module 90 and the 
disparate subsystem managers 100 provides a reliable trans- 
parent foundation for communications between disparate 
subsystems 20 within a mobile unit through the use of a 

45 selected common protocol that permits seamless integration 
among all disparate subsystems 20. llic communication 
apparatus 22 utilizes operating system features that promote 
portability (POSIX), so thai the communications apparatus 
22 Ls portable to any POSIX-complianl operating system. 

50 Processes attach to the communications apparatus 22 as 
"components" providing services (access to a protocol, 
application performing data-reduction, interface to data 
input device, etc.). Each component provides an interface 
using the communications apparatus 22 API (application 

55 programmer's interface) and, for a particular disparate sub- 
system 20, an interface to a native protocol or interface. 

The communications apparatus 22 also promotes dynamic 
operation. As a new component Ls executed (either at boot- 
time or any lime thereafter), it regLsters itself with the 

oo common module 90. This registration allows other compo- 
nents to know who is connected and to some extent whal 
services they provide. When a disparate subsystem 20 or 
other, component wLshes to be removal from the commu- 
nications apparatus 22, dc -registration occurs to remove its 

65 name from the common module 90 name-space. 

The combination of the common module 90 and disparate 
subsystem managers 100 creates a common denominator for 
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communications such that alt components speak at least one 
common language (common protocol) and thus provide the 
capability to communicate to one another. The communica- 
tions apparatus 22, which must support dynamic operation 
and transparency, provides a naming facility to achieve these 5 
goals. 

The name-space within the communications apparatus 22 
is split into three distinct regions. A physical name is defined 
as a 10-bit value (0-1023 possibilities). 

10 



Region 


Name 
sub-space 


Description 


System Names 


nOOO-0127 


system names (reserved 






for core platform name. 


Dynamic Names 


0128/0511 


dynamic names (allocated 






through the system 






dynamically) 


User Names 


0512-1023 


user name space 






available for OEM use. 


Broadcast 


1024 


all registered names 



20 



25 



35 



Names can be cither static or dynamic, which is defined 
by the method used to attain them. Static names are simply 
defined to the system during registration, where dynamic 
names are requested from the common module 90. As a 
general rule, names should be dynamic unless they are 
required to be static An advantage lo static names is that Ihey 
are always known (the mapping from name lo component 
remains fixed) which is why servers are typically static. 30 
Dynamic names arc useful for client components that do not 
export functionality (do not require a component lo asyn- 
chronously communicate with it). An exception lo this rule 
is made possible by a services API. The primary goal of the 
services API is to limit the static usage of the software bus 
naming service. 

One of the primary uses of dynamic names are the 
dynamically created children of server components that 
manage specific communications. These children register ^ 
with a dynamic name, since the child communicates only 
with components that requested information from the server. 

One special name is the broadcast name. This name 
results in the message lo be sent being distributed to all other 
registered components except for the original sender. Mul- 4S 
ticast communication is also available where components 
arc permitted to subscribe to a particular "list." Whenever a 
message is sent lo the identifier representing the list, each 
member associated with the list receives a copy of Ihc 
message. <jq 

ITie services API provides the means to identify function- 
ality exported by dynamically named componcnis. Ascrvicc 
is a simple string that defines some unique information about 
the component to the communications apparatus 22 and to 
other componcnis. For example, the GPS manager 112 could 55 
register itself with a dynamic name (received through the 
communications apparatus 22) and then identify its service 
to the bus using the publicly available key "OPS". Other 
components looking for the GPS manager 112 could per- 
form a simple lookup using the "GPS" public key, which 6 o 
would result in the return of the component's physical name. 
'I lie ability to wait for a service name is also provided which 
introduces the capability of component synchronization. 

Communication among components connected to the 
communications apparatus 22 requires a definition of rules, 65 
called protocols, to govern the manner in which communi- 
cation is allowed to take place. A protocol is a formal set of 



rules and conventions governing the format of message 
exchange between two or more communicating components. 
The communications apparatus 22 provides two protocols 
through two APIs, identified as bus API and stream API. 

The bus API is the lowest level of communication. It 
provides packet level communication between components 
registered with the common module 90. The next level up is 
the stream API that uses the bus API as its base. Each of the 
bus and stream APIs are part of the common module 90. The 
stream API provides point-to-point stream data communi- 
cation. Bus communication is useful in applications where 
communication must be performed to a number of indepen- 
dent components. Stream communication is useful for 
unstructured stream data between two components (such as 
an audio stream). 

llie communications apparatus 22 utilizes messages in 
communicating with components connected thereto. Ames- 
sage is a typed collection of data objects consisting of a fixed 
size header and a variable length body that is managed by a 
component. A type is associated with a message to provide 
structural information on how the message should be used. 
Messages provide the basic object for communication over 
the common module 90 and representative message content 
is provided below: 





Source 


the sending component 




Destination 


the destination component 


Message Header 


Type 


the message type 
(structural id) 




Ixngth 


the length of the data 
portion 


Message Bufler 


Variable Data 





Bach registered component is assigned a message queue 
for the receipt of messages. The component should manage 
this resource carefully to be a good neighbor on the bus 
(respond in a timely manner, etc.). livery lime a message is 
sent using one of the available send primitives, it is placed 
on the queue defined by the component destination (the 
message queue owned by the destination component). In 
some cases, a component may register more than once. 
Incrctorc it is important to note that a component identifier 
may not refer to a component but instead of a specific queue 
of a component. 

Communications apparatus 22 communication primitives 
operate in either blocking or non -blocking modes. In block- 
ing mode, the sender blocks (sender waits until the message 
has been placed on the receivers message queue). In non- 
blocking mode, the sender returns immediately with an 
indication of whether the message was placed on the queue 
or not. Conversely, receiving messages operates using the 
same semantics. In blocking- mode, a receiver blocks if no 
message is available for read. In non-blocking mode, the 
receiver is returned an indication of whether a message was 
received or not. 

Messages arc owned by each component and arc allocated 
from the process-specific address-space (rather than system- 
owned messages). 

Since the communications apparatus 22 is a networking 
product, communicatioas with entities that differ in process- 
ing architecture arc inevitable. Issues that arise here arc 
byte-endianess, structure packing issues and data represen- 
tation issues. Not all of these problems can be completely 
resolved (unless a single unified architecture exists) so 
standards arc defined here. 
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The byte-endian issue is resolved through the standard 
networking practice of network byte order. The Power PC 
provides this by default, so extra computing is not required 
to provide the byte swapping. 

Structure packing issues come into play when an external 5 
process sends a message to a component of the communi- 
cations apparatus 22 using a structure cast to a void pointer. 
For efficiency, packing is performed on 33-bit boundaries. 

Finally, representation issues manifest themselves 
through the fundamental types of a particular architecture 10 
(for example, floating point). Numerous floating point rep- 
resentations exist and since the system cannot understand 
them all, floating point will be disseminated in the Power PC 
format. Knowing this information, externa] applications can 
provide conversion functions to convert the floating-point 
data to their specific representation. Applications may con- 
vert floating-point data to scalars or simply pass ASCII- 
based representations to further simplify this problem. 

The lowest level of communication offered by the eoni- 
municalioas apparatus 22 is the packet-level (or bus-level ^ 
since it is the bus-native format). Communication at this 
level is direct in that a recipient is defined for each message 
that is sent by a component. Addressing at this level is 
symmetric given a recipient is defined for each message and 
also a recipient handle is defined for a bus-level receive 
operation for a component. 

Prior to a component communicating over the common 
module 90, it must first register. The registration occurs with 
the base manager 170. Once registration has occurred, Ihe 
component may send and/or receive messages over the M) 
communications apparatus 22. When communication is no 
longer necessary, dc-rcgist ration occurs. This process is 
again managed wiih the base manager 170 through the bus 
API. 

The bus-level also provides other useful functions such as 35 
dynamic name request, name lookup and a default message 
handler. 

Hie communications apparatus 22 can provide different 
messaging functions including broadcast messaging and 
multicast messaging. Broadcast messaging is achieved by 40 
sending a message lo a special destination name, which 
results in the message being sent lo all registered compo- 
nents. Broadcast is a useful mechanism on the communica- 
tions apparatus 22 for synchronized start and shutdown. 

In some applications there is the need for multicasting, 45 
which allows a subset of the communications apparatus 22 
to receive messages of the same type. Multicasting is 
provided by the communications apparatus 22 through the 
registration of a dynamic name that represents the list of 
multicast members. A multicast list may be defined as a 50 
service. Therefore, other components may identify a multi- 
cast address by a particular name and/or wait-for it using the 
service AIM synchronization. 

AI>ove the bus-level of communication are stream com- 
munications. Streams, as the name implies, are point -to- 55 
point connect io as between two components where unstruc- 
tured data is moved between them. The primary difference 
between streams and the bus- level AIM is that streams permit 
a connection to another component and then one-to-one 
communication. The stream API provides communication 60 
primitives (such as send and receive) but also server-specific 
primitives for developing information servers. Stream level 
communication utilizes simple streams of byte-data rather 
than structured messages. Once the connection occurs, byte- 
dala is streamed between the two end-points. Stream primi- 65 
lives may be configured for blocking or non-blocking opera- 
tions based upon parameters passed at stream connect. 



Since the communications apparatus 22 is an open archi- 
tecture and, depending upon the particular application, 
highly available through a number of links, security is a key 
issue. Security can be established on three fronts. The first 
is external user access, the second is application and the 
third is data. Each level is dependent on the next for security. 
Communication security comes into play when external 
entities desire connectivity to or from the communications 
apparatus 22. Basic security mechanisms protect against 
access through telnet, ftp or tftp (standard UNIX® 
mechanisms). 

Application security is required for external applications 
that wish to connect to the communications apparatus 22. 
When an external application wishes to connect to the 
communications apparatus 22, the security manager 184 of 
the communications apparatus 22 is consulted first to iden- 
tify if the connection is authorized (through its internal 
security directives). For example, when an external appli- 
cation connects through the TCP/IP manager 110, the secu- 
rity manager 184 will define whether the connection is legal 
by identifying the host of the external application. The 
security manager 184 defines not only whether a connection 
is legal by identifying the host of the external applications 
but also whether the particular destination of the connection 
is acceptable. By way of further example, the security 
manager 184 may define that the TCP/IP connections arc 
approved from a first host to the USB manager 126, but not 
to the OBD manager 118 or a second host associated with 
the IDB 28 may access the GPS 26, but not the TCP/IP 24. 

Data security is provided through the use of the encryp- 
tion service manager 214 that encrypts data prior to being 
shipped through the link. Conversely, decryption managers 
of the common module 90 function lo decrypt data from an 
outside source into the communication apparatus 22. 

'Hie communications apparatus 22 operates in two basic 
functional modes. 'Iliesc are identified as the "pure bridge" 
mode and the "application" mode. 

In pure bridge mode, the communications apparatus 22 
opcratcs.using two protocol managers (e.g. IP/TCP manager 
110 and IDB manager 114) to create and maintain connec- 
tions essentially controlled by a source or application 
located outside Ihe environment of the communications 
apparatus 22. One such manager acts as the source protocol 
manager for the incoming connection and the other such 
manager acts as the destination protocol manager. The 
transferred data or other information is not destined for use 
internally but is lo be moved from one subsystem (e.g. bus) 
to another subsystem. Applications running in external 
nodes operating over different buses force the creation of 
connections which bridge the available buses or links within 
the vehicle or other environment. 

For example, consider the communications apparatus 22 
providing connectivity to TCP/IP 24, IDB 28 and GPS 26. 
The TCP/IP 24 and IDB 28 arc provided through the TCP/IP 
and IDB managers 110, 114 and the GPS 26 is provided 
through the GPS manager 112. These software components 
execute as part of the communications apparatus 
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Manager] jo 



GPS Device 
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Consider a node connected lo an IDB device, stack 220 
that wishes to gather vehicle location data and then com- 
municate this data to the external nodel 80a on the Internet. 

lhc IDB application connects to the communications 
apparatus 22 node using the IDB device stack 220 and the 
IDB manager 114 with a packet header defining the action 
lo take (connect to the GPS manager 112 utilizing the GPS 
interface 224). The IDB manager 114 would create a child 
component (along with the GPS manager 112) lo provide the 
read-only data through the IDB device stack 220 back to Ihe 
requesting application. This connection could be stream- 
based (data would stream to the IDB-bascd external appli- 
cation when updated, or could be asynchronous in a request/ 
response mode) 'Hie IDB application next connects to the 
TCP/IP manager 110 (utilizing the socket interface 228) with 
another packet header (specifying the requested connection 
to the TCP/IP manager 110 along with the external host for 
which the connection should be made). The TCP/IP manager 
110 would then make the connection to the external host, 
and bind a child process to handle the particular connection. 

Hi is process is identical regardless of the particular 
network being used by the connecting application, for 
example the USB 40 would use the same process. Applica- 
tions can also create connections through TCP/IP 24 thereby 
providing Internet -based enterprise level access lo devices 
connected to the communications apparatus 22. The security 
manager 184 limits access to only appropriate hosts. 

Stream modes of communication (for unstructured data) 
and packet modes (for structured data) arc provided through 
the communications apparatus 22. 

The previous section defined a mode whereby a protocol 
(TCP/IP 24) and a device manager (GPS 26) provided Ihe 
necessary functionality to bridge a device and route between 
protocols for externally controlled applications (external 
applications arc in control of data flow through the commu- 
nications apparatus 22). The application mode differs in that 
the users of the data can be maintained on the communica- 
tions apparatus 22. 

The communications apparatus 22 provides an open 
architecture for the development of onboard applications, A 
developer can link the communications apparatus 22 librar- 
ies lo gain access lo the communications apparatus 22 to 
connect to any manager (protocol, device or other). The 
APIs are consistent among all components, the data simply 
differs to change Ihe behavior of the communication. 

Outsider the following example utilizing voice recogni- 
tion and tcxt-lo-spccch in a vehicle application. The voice 
recognition (VR) manager 142 provides a server using 
existing VR technology 56. 'Die VR manager 142 accepts 65 
the recognized speech in terms of grammatical tokens that 
identify the parsed sentence. The VR manager 142, in this 
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application, requires that any voice command be preceded 
by a destination entity (for example, browser, GPS, etc.). For 
example, "browser, search for X". This prefix identifies to 
the VR 142 manager the destination of the particular speech 
unit. 



Browser 




Cell Phone 


Manager 




Manager 150 
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TCP/IP Protocol 




ITS 




VR 


Manager | 10 




Manager H6 




Manager 



TCP/IP 
Staclc2< 



'ITS Technology 



VR Technology 
56 



Applications connect lo the VR manager 142 defining 
their particular name such as "browser" or "cellphone". A 
speech is recognized and parsed, the speech tokens are 
passed to the particular manager. 

In this application, the browser manager 138 would notify 
the VR manager 142 that it is available and its name is 
"browser". This defines the browser 52 as a user of the VR 
manager 142 and a destination for speech preceded by the 
name. When the VR manager 142 (using the available 
driver) parses the sentence "browser what is the nasdaq 
doing?", the word-tokens arc passed to the browser 52 (or 
more likely through a parser which identifies the semantics 
of the request who then passes the raw information to the 
browser 52). If the sentence is not understood by either 
entity, the text-lo-spcech (ITS) 146 manager is provided 
with a canned "I do not understand your request" statement. 
Otherwise, the browser 52 tries to satisfy the request (likely 
through the TCP/IP manager 110) and then returns the result 
back through the ITS manager 196. I Tic TCP/IP manager 
110 may involve the TCP/IP disparate subsystem 24 as part 
of gathering requested information outside of the vehicle, 
which information is located at a remote site, such as a web 
site. 

This illustrates the application mode of the communica- 
tions apparatus 22 where data management is essentially 
under control within the vehicle or other environment in 
which the communications apparatus 22 is located. It should 
be noted that the VR manager 142 could be used in bridge 
mode as well, where an external application could register a 
name and the speech tokens would be routed to the particular 
application on its bus (IDB 28, USB 40, etc.). 

An additional description related to the components and 
operations of the system is next provided with reference to 
FIG. 2. A now processing diagram is depicted related to 
functions, operations and steps associated with obtaining 
information from inside a vehicle having Ihe communica- 
tions apparatus 22, pursuant lo a request from an outside 
source or destination that is external to the vehicle. 
Generally, in accordance with this representative example, 
Ihe source or remote stations is seeking vehicle information 
related to vehicle position and engine speed. Such informa- 
tion is in the form of data obtained from the GPS subsystem 
26 and the OBD-II subsystem 32. The GPS subsystem 26 
has position data in the form of latitude, longitude and 
altitude associated with the vehicle. The OBD-II subsystem 
32 includes data related to engine speed. 

In this embodiment the source seeking such data develops 
a configuration packet 300, which has the necessary request 
information including a destination, services that might be 
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invoked, and data or other information being requested. In manager 184 may utilize a. list, which identifies authorized 

this example, the configuration packet 300 may be defined users and/or what information or other accessing this user 

as having a number of fields that convey what is being (source) might be entitled to. Based on this checking, the 

requested by the source. The configuration packet 300 can security manager 184 determines that this request from the 

include information related to the identity of the disparate 5 identified source is authorized. This determination allows 

subsystem from which data is being requested, such as the the common module 90 and necessary managers 100 to 

GPS disparate subsystem 26. Associated with Lhis particular continue their task in connection with satisfying the contents 

subsystem, the data being requested is identified in a further of the configuration packet 300. 

field, namely, the NMEA conventionally identified data from In view of the data being requested, a stream API is to be 

the GPS subsystem 26. As part of the GPS field, it may have J0 employed in transferring, the requested data. In conjunction 

a number of sub-fields that particularly identify GPS with that, the TCP/IP manager 110 creates a TCP/IP child 

parameters, such as one or more of latitude, longitude and process 310 that will be involved in sending the requested 

altitude as part of the data transfer from the vehicle to the data from the vehicle using a socket interface associated 

source. l ; or one or more reasons including security, the with the TCP/IP subsystem 26. When created, the TCP/IP 

configuration packet 300 also requests that the returned data 15 child process 310 is registered with the common module 90 

from the vehicle be encrypted so that this service request is using the base manager 170. Thus, for this particular data 

also part of the configuration packet 300 and can have an transfer, this dynamically created process and identifier is 

identifier (Id 1) associated with it. In conjunction with the involved with the TCP/IP transfer, while other TCP/IP 

encryption request, a key accompanies the con figuration transfers could be accomplished under management/control 

packet 300 related to how the data being obtained is to be 20 of the TCP/IP manager 110. 

encrypted. A further service being requested with this data with respect to the configuration packet 300 being sent to 
traasfcr, for one or more reasons such as the amount of the t hc flow manager 192 and its responsibilities, upon reading 
data being requested, the configuration packet 300 also has (n e configuration packet 300, the flow manager 192 rccog- 
a compression service request by which the requested data n j 7XS that GPS data and OBD-II data arc being requested, 
will be compressed before sending from the vehicle to the 25 Th c fl ow manager 192 generates a message including a 
source. An identifier (Id 2) can also be associated with this request to thc GPS manager 112 by which the data being 
particular service request for any desired identification pur- requested from thc GPS subsystem 26 can be obtained. In 
pose. As part of this service, the source can perhaps select that regard, thc GPS subsystem 26 is inputting thc NMEA 
one or more algorithms that would be utilized in providing data to the GPS manager 112, which data can be readied for 
the compression and such as identified in one of thc fields of 3U transfer along a determined path. In that regard, thc flow 
thc configuration packet 300. manager 192 is also involved with satisfying further require- 
As previously noted, thc data being requested is not only ments related to the data transfer including the compression 
from thc GPS subsystem 26 but also from thc OBD-II and the encryption services that were requested, 
subsystem 32. Thus, thc configuration packet 300 also Furthermore, because in this example OBD-II data is also 
includes similar fields to identify thc particular subsystem 3S being requested, the flow manager 192 is used in generating 
from which data is being requested (OBD-II subsystem 32), a mela -child process 320 for desirably enabling and facili- 
togethcr with the particular data, such as engine speed. In lating the two sets of data transfer. The meta-child process 
this example, this data is a 1st) to be encrypted and com- 320 is also registered using the base manager 170 with the 
pressed using the same key and algorithm associated with common module 90. Thc meta-child process 320 acts as a 
(he GPS data. 40 handler and is otherwise responsible for managing the 
After the configuration packet 300 has been prepared, it obtaining of GPS data and thc OBD-II data. Accordingly, a 
can be transmitted, including wirelessly, from thc source to GPS data stream is provided to thc meta-child process 320. 
thc vehicle. In a preferred embodiment, thc transmission of Similarly, the requested engine speed data from the OBD-II 
this configuration packet 300 utilizes thc Internet and with at subsystem 32, in thc form of a data stream is handled by thc 
least thc vehicle to which the configuration packet 300 is 45 meta-child process 320 through the OBD-II manager 118. 
being sent having an Internet address, which accompanies Continuing with a description of this example of 
the configuration packet 300. Thc recipient device in the operation, thc flow manager 192 is also involved with thc 
vehicle of such a configuration packet is thc wireless device spawning of a compression agent or child process 330 and 
or cellphone 64, as well as a wireless modem associated an encryption agent or child process 340. Cach of thc 
therewith. 'Die configuration packet 300 from the Internet 50 compression agent/child process and encryption agent/ 
using TCP/IP is received by thc TCP/IP subsystem or process 330, 340 are registered with the common module 90. 
protocol slack 24. This subsystem can handle and act on the Like the stream API that is established for transferring the 
received configuration packet 300 including recognition of GPS data using the meta-child process 320, a stream API is 
thc associated address. In direct communication is the TCP/ utilized in transmitting the combination of GPS and OBD-II 
IP manager 110 which reads thc configuration packet 300. 55 data using the compress child process 330 from the mela- 
Upon such reading, among other things, it is recognized that child process 320. The compression child process 330 has 
the configuration packet 300, given its request, is appropri- responsibility for compressing the GPS and OBD-II data 
ate for functions to be performed by thc flow manager 192 using thc compression operation or algorithm identified in 
of the common module 90. Hence, the configuration packet the configuration packet 300. This compressed combination 
is also sent to the (low manager 192. &o of data can then be encrypted using thc encrypt agent or 
As part of this operation description for obtaining such encryption child process 340, as the compressed data under 
data, thc configuration packet 300 is applied to the security a stream API connection interface is received by thc encryp- 
manager 184 of the common module 90. Thc security lion child process, 340. This child process 340 encrypts the 
manager 184 is used in determining whether or not thc two sets of data using thc supplied key from thc configu- 
source, together with the information being requested, has t>5 ration packet 300. 'Die compressed and encrypted GPS and 
authorization to use (he communications apparatus 22 and OBD-II data can then be sent wirelessly to the requesting 
obtain thc requested information. In that regard, thc security source under the management/control of (he TCP/IP child 
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process 310 through the TCP/IP subsystem 26, with reliance applications connected to the communications apparatus 22 

on the same Internet technology and wireless technology through one of the defined common protocols and then 

that provided the request from the source in the form of the connect to another protocol or device to communicate. The 

configuration packet 300. second mode provides a bridging and routing function 

As can be appreciated, numerous variations and adapta- 5 between different protocols where essential control exists 

tions can be implemented utilizing the basic architecture of outside the communications apparatus 22. The communica- 

thc common module 90 and the managers 100. For example, lions apparatus 22 has particular applicability in a vehicular 

instead of the flow manager 192 spawning the compression environment and serves as a router/server. In a vehicle, the 

agent 330 and the encryption agent 340, the compression communications apparatus 22 provides the ability to route 

service manager 210 and the encyrption service manager 10 between a number of different protocols and buses as well as 

214 could take responsibility for the requested compression manage one or more wireless links. Fundamentally, in the 

and encryption functions. Instead of the described usage or vehicular environment, the communications apparatus 22 

reliance on the flow manager 192, the TCP/IP manager 110 bridges disparate vehicular buses to permit resource and 

and/or GPS manager 112 could have more managerial information sharing, bridges vehicular buses and one or 

responsibility related to the processing and flow of the 15 more wireless links, allows for dynamic selection of wire - 

requested data. The GPS manager 112 might be involved in less links and bridges between consumer/entertainment 

the spawning of the mcta-chiid process 320. The TCP/IP buses. Particularly in the context of vehicle applicability, the 

manager 110 may send the configuration packet 300 to the communications apparatus 22 of the present invention facili- 

GPS manager 112. Alternatively, instead of the essentially tales the following applications: data logging/reduction, 

dynamic routing that occurs through the receipt and use of 2 o vcmcle diagnostics, fuel management, engineering data 

the configuration packet 300 by the communicatioas appa- gathering and/or processing, vehicle location and mobile 

ratus 22, an alternative kind of routing involving the com- olficc features. The communications apparatus 22 has 

municalions apparatus 22 might be based on the use of one enhanced the interoperability in the communications field by 

or more port numbers. From the identified port number enabling communications among non-standard and 

associated with the communications apparatus 22, the input 2 s standards-based technologies. The communications appara- 

requcsl may be routed directly to that port. Similarly, a tus 22 not only interprets the variety of protocols used within 

communications apparatus destination identification may be a vehicle but allows Internet protocol capability to be 

provided to the communications apparatus 22, which is conveyed over a variety of wireless network standards, 

mappablc to a particular component of the communications Applications for the communications apparatus 22 can be 

apparatus 22. j 0 developed using software libraries associated with the com- 

In further understanding and/or disclosing the inventions, municalions apparatus 22. 

particularly as related to selection of desired communication The communications apparatus 22 allows direct conncc- 

links or channels, U.S. Ser. No. 08/778,897 filed Jan. 3, 1 997 tion to vehicular signals such as by way of the CAN, RS232 

is hereby incorporated by reference in its entirety. and Ethernet. Application software can be developed to poll. 

Based on the foregoing description, it is seen that the 35 filter, collect, process and store data collected from the 
communications apparatus 22 provides a software frame- vehicular network. The communications apparatus 22 can 
work for the development of complex communication sys- Lssuc commands to such bus interfaces for interrogation and 
terns. It provides a set of core APIs that provide communi- control of peripheral bus-connected devices, such as the 
cation primitives and also service advertisement, data CJPS or an engine control module. Almost any local bus can 
broadcast and multi-cast and event synchronization. Irie 40 hc accommodated using suitable hardware and software, 
communications apparatus 22 permits dynamic plug-and- Proprietary bus or data-gateway interfaces can be developed 
play registration and de-regislration from il which provides for special applications. The communications apparatus 22 
for a completely dynamic and run-time configurable archi- can also be configured as a gateway between multiple 
lecture. ITic architecture provides a simple set of APIs for vehicular local buses to allow the various elements that 
communication systems development. The architecture may 45 communicate with each other. Some examples of vehicular 
be easily extended with new drivers and applications. The data sources arc transponders, sensors, timers, engine con- 
communications apparatus 22 has a dynamic feature in that lro1 components, operator data interfaces, as well as the 
software components may engage and disengage from it GI>S - ^ ata from the host sent to the vehicle to communicate 
when desired. The communications apparatus 22 has a with the operator, provide GPS information, run diagnostic 
transparency feature in that components arc decoupled 50 routines, reconfigure data collection routines, download 
through the message -passing architecture. The architecture code and run executable software. Analog and digital signals 
promotes software reuse through standard components that a ™ acquired using vehicular networks or common serial 
provide inlergmwlh functionality. The communications interfaces. Some vehicular networks also include short range 
apparatus 22 enhances platform independence, particularly wireless LANs for data collection and user interface require- 
by the use of the POSIX layer of a RTOS so il is portable to 55 mcnls. 

different operating system and hardware architectures. The A further enhancement of the present invention is next 

communications apparatus 22 provides a framework to described with reference to FIG. 3. In an embodiment 

simplify development by providing a common interface to a utilizing the technology of FIG. 3, communications involv- 

variety of protocols and interfaces. A plug-and-play building ing a number of communication apparatuses 22 located, for 

block approach to systems development allows developers oo example, in a number of vehicles arc facilitated. Such an 

to quickly bring products to market using the communica- embodiment has particular utility in the context of a number 

lions apparatus 22 in addition to reducing their overall of vehicles owned/operated by the same entity. 'Iliis appli- 

developmenl cost. Hie communications apparatus 22 pro* cation may involve a vehicle fleet entity having a number of 

vides two modes of operation. An application mode allows vehicles, with each of the vehicles being monitored, as well 

applications connected to the communications apparatus 22 f>5 as supplying information to them. 

to utilize connected interfaces by means of common proto- Functions and objectives related to managing such 

cols. The second is a bridge mode that allows external embedded computer apparatuses 22 within a fleet of vehicles 
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include: properly and securely reconfiguring software on the 
communications apparatus 22; properly and securely updat- 
ing software on each such apparatus 22; diagnosing prob- 
lems associated with each communications apparatus 22; 
and monitoring operation and routinely providing status 
information associated with each computer apparatus 22. 

To achieve these objectives and functionalities, FIG. 3 
illustrates a system 300 characterized by a management 
portal apparatus or module 310. The portal apparatus 310 is 
separate and remote from each of a plurality of communi- 
cations apparatuses 22a, 22b . . . 22n. The portal apparatus 
310 communicates with each of the communications appa- 
ratuses 22a-22n, which may be embedded in different 
vehicles and constitute a fleet of vehicles, by means of a 
wireless network 314. The wireless network 314 can include 
the Internet 320 and its associated technology. 

The system 300 also includes one or more vehicle fleet 
subsystems 324a . . . 324/1. Each of these fleet subsystems 
324 is typically located at the facility of a particular vehicle 
fleet owner/operator. Each fleet subsystem 324fl . . . 324n 
can include fleet manager hardware and software 
(processing and controlling capabilities). 330^-330/1, 
respectively. Such hardware and software is involved with 
managing the communications, such as requests and 
commands, or otherwise controlling the flow of information 
related to the member/vehicles in the vehicle fleet or set. By 
way of example only, the fleet manager 330a may manage 
one or more of the vehicles having some of the communi- 
cations apparatuses 22a . . . 22/j, while the fleet manager 
330w may be involved in managing others of the vehicles 
having different ones of the communications apparatuses 
22<i-22/i. With regard to maintaining or storing data or other 
information related to the vehicles that they manage using 
the respective communication apparatuses 22, each fleet 
subsystem 324 communicates with and has responsibility 
over a fleet data memory or storage 334, which is part of the 
particular fleet subsystem 324. Each such fleet data memory 
334« . . . 334/1 can store data obtained from the vehicles in 
the fleet for later access and use, particularly evaluation and 
analysis, such as in the conlext of monitoring vehicle data 
related lo proper operation of the vehicle. 

With respect to communications with one or more fleet 
vehicles of a particular fleet subsystem 324, the Internet 320 
is preferably involved by which each such fleet subsystem 
324 can access the portal apparatus 310. In providing 
services and functionalities requested by the fleet sub- 
systems 324, the portal apparatus 310 acts as a web -based 
interface or middle-ware component useful in managing one 
or more devices in each vehicle of the fleet -and monitoring 
them for proper operation. Generally, the services and 
functions of the portal apparatus 310 can be construed as 
involving data management or system management, llic 
tasks and operational steps associated with data management 
that can be conducted involving the portal apparatus 3 10 can 
be as varied and ubiquitous as necessary for the fleet entity's 
requirements. Since system management is less diverse 
(customization for a particular fleet subsystem 324 not as 
prevalent), the system operation of the portal apparatus 310 
can be dcserilxd more completely. 

\J\c portal apparatus 310 is a "port-of-entry" for access to 
fleet information. The portal apparatus 310 provides a web- 
based interface to a particular set of information and allows 
authorized personnel to review information on their respec- 
tive communications apparatuses 22. Additionally, updated 
and/or new software can be identified that is of relevance to 
the particular fleet (new or updated managers, more than 
trivial software bug-flxes, etc.). The portal apparatus 310 
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provides a web-based interface such that the communica- 
tions apparatuses 22 in the field can be scheduled for remote 
maintenance whether software and/or configurations are 
updated based on the desires of the particular fleet owner/ 

5 operator. The portal apparatus 310 can also act as a notifi- 
cation service provided such that fleet managers 330a . . . 
330/1 are notified of issues when they occur. 'Ill is is in 
addition to the previously noted functionalities such that 
managers can browse assets as well as set triggers for 

10 automatic notification. The portal apparatus 310 includes a 
fleet management system 340 in the form of appropriate 
hardware and software involved in managing or controlling 
communications with the communications apparatuses 22 in 
vehicles of one or more fleets, together with communica- 

15 lions involving the one or more fleet subsystems 324. The 
portal apparatus 310 also includes a central fleet data 
memory or storage 334 that contains parsed information 
received from the numerous communications apparatuses 
22. T*he information is received in a variety of forms, 

20 depending upon the link device used within the communi- 
cations apparatus 22, such as e-mail via pager, stream socket 
via CSC, etc. 

With regard to reconfiguration updates, each communi- 
cations apparatus 22 is a highly configurable unit that 

25 permits the execution of numerous applications satisfying a 
number of different requirements. 'ITie ability to reconfigure 
applications at any time is a challenge since vehicles can be 
located anywhere in the country, depending upon the cus- 
tomer. Hence, there is a need to remotely reconfigure and/or 

M) updale software on one or more communications appara- 
tuses 22 safely without creating the need for hands-on access 
to the particular communications apparatus 22. In conjunc- 
tion with achieving this objective, a "transaction-based" 
solution is utilized to insure the integrity of the particular 

35 communications apparatus 22 after any change has 
occurred. In providing a new configuration or software 
update, it is preferably sent as a single file from the portal 
apparatus 310 to the one or more selected communications 
apparatuses 22 through the wireless network 314. I*he single 

40 transfer involving all updates for a particular communica- 
tions apparatus 22 better avoids missing one or more files 
due to communication or user error. Once the updated 
information (different configuration of software) arrives at 
the particular communications apparatus 22, it is verified. 

45 Such a verification can be accomplished using a checksum 
or other integrity checks. After doing so, the update is 
applied to the particular communications apparatus 22. 
Applying the new configuration or update is performed in a 
secure fashion whereby changes arc not immediately applied 

50 to active files in the communications apparatus 22 hut 
instead to mirrors of (he targeted files. In that regard, the 
configuration manager 180 is responsible for updating soft- 
ware and/or a con figuration for a particular communications 
apparatus 22. Upon receiving the new configuration or 

55 software update, the configuration manager 180 is respon- 
sible for extracting changes from the configuration in the file 
and applying them to the communications apparatus 22 in a 
shadow or mirror form. Once application of the file is 
complete, the configuration manager 180 performs a post 

60 update check and then notifies the portal apparatus 310 that 
the operation was successful. More particularly, when the 
new configuration or software update arrives from the portal 
apparatus 310, the configuration manager 180 updates, 
shadow files in the particular communications apparatus 22. 

65 Once the configuration update is approved, (he configuration 
manager 180 migrates the shadow files to the active or 
current file. A post update check is made. 'VUc portal appa- 
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ratus 310 is notified of the successful updating. Once 
notified, the portal apparatus 310 is aware of the new 
configuration or update. 

An unsuccessful reconfiguration results in file histories 
and checksums being sent back to the portal apparatus 310 
in order to reconstruct the update process and provide 
another configuration to bring the particular communica- 
tioas apparatus 22 up to the desired revision. The update 
process can be customer driven, based on updated software 
for new requirements, or by the recommendation of the 
portal apparatus 310. The portal apparatus 310 is aware of 
which communications apparatuses 22 use a particular revi- 
sion of software. In that regard, the configuration manager 
180 has the capability to interrogate a communications 
apparatus 22 and identify the revision(s) of software and 
configuration being used by that particular communications 
apparatus 22. 

The system 300 also has the capability where components 
thereof may be applied with an indication of their priority or 
need for update. With that information, the portal apparatus 
310 can automatically notify the fleet owner/operator of 
changes that were incorporated. Such notification could 
include what needs to be changed and the objectives sought 
to be served by making the changes, such as bug- fixes, new 
functions, etc. Based on the notification, the fleet manager 
330 of a particular fleet subsystem 324 could then direct the 
portal apparatus 310 to update one or more communications 
apparatuses 22 within the domain of that fleet subsystem 
324. Such a process involving automated updating and 
notification would require dependency analysis to under- 
stand the dependencies among components for proper 
operation, but the process could also be automated to 
integrate customers into the evolution of the software. 

Further functionality associated with the portal apparatus 
310 involves the gathering of diagnostic and operational 
data from the communications apparatuses 22. Such data 
enables the system and its users to understand how the 
communication apparatuses 22 are used and under what 
conditions, which information is beneficial in optimizing 
and enhancing its operation and functionality. Diagnostic 
data for such purposes can be emitted in a special com- 
pressed form to the portal apparatus 310 whereby the 
operatioas of the communications apparatuses 22 in the Held 
are monitored and corrective actions can be taken when data 
indicates that such correct ioas arc necessary or appropriate. 

In connection with taking responsibility for handling 
diagnostics data, the diagnostics manager 182 is involved in 
collecting and relaying diagnostic data from the communi- 
cations apparatus 22 to the portal apparatus 310. More 
particularly, within the communications apparatus 22 as the 
managers are made aware of activities that are not normal or 
need to be reported (time-outs expired, resources 
unavailable, etc.), they notify the diagnostics manager 182. 
At the same time, the diagnostics manager 182 is collecting 
secondary data such as current available memory, tempera- 
ture of the communications apparatus 22, process load, 
altitude, current time, as well as other relevant information. 
"Iliis data is compressed such that its transmission docs not 
overload the available communications link. In that regard, 
the diagnostics manager 182 must also be configurable to 
limit data and emission when links, such as pager devices, 
arc used, liach data piece can be accompanied by a severity 
indicator (informational, warning, error, etc.) so that the 
diagnostics manager can limit (heir emission when desired. 

Diagnostic data can corne in many forms and the diag- 
nostics manager 182 receives data from operating managers 
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as well as collecting parameters itself from pertinent parts or 
components of the communications apparatus 22. Collected 
events or other information are compressed to do a stream 
that, on a periodic basis or depending upon severity of the 

5 event, are transmitted to the portal apparatus 310. The 
diagnostics manager 182 based upon the configuration of the 
particular communications apparatus 22 also filters the 
events. For example, in a communications apparatus 24 that 
has routine access to a CDPD connection, all events may be 

10 emitted including informational and warning messages. In a 
communications apparatus 22 that has only access to a 
two-way pager device, only critical and error events arc 
emitted to reserve bandwidth for actual applications. 
The result from the particular communications apparatus 

15 22 is a fusion of data from numerous applications into a 
compressed stream of data that can be later decompressed 
and automatically parsed and archived at the fleet data 
memory 334 or central storage 344 of the portal apparatus 
310. The stream represents a history of the operation of the 

2Q particular communications apparatus 22 that can be used to 
reconstruct the occurrence of a failure or intermittent prob- 
. 1cm within the communications apparatus 22 to identify its 
cause. The benefit relates to the ability to correlate an error 
that appears in one communications apparatus 22 with other 

25 such communication apparatuses 22 that function similarly. 
Based on such a mass of information, errors or other 
unwanted functioning can be better handled 

Related to obtaining diagnostics data from one or more 
communications apparatuses 22 is the handling of such 

30 received data by the portal apparatus 310. llic majority of 
such data represents informational events that are simply 
logged within the portal apparatus central memory or data- 
base 344. An error of one or more events can be (lagged for 
review or e-mail could be generated to inform a recipient 

35 through event filtering and notification of a critical event that 
requires immediate attention. The particular fleet subsystem 
324 could also be notified so that it is up-to-date on the status 
of its fleet. The portal apparatus database 344 is both 
hierarchical and temporal in nature. At an upper level are the 

40 identified fleets. At lower levels and associated therewith are 
the particular vehicles within the fleet and their specific 
configuration information. For each vehicle, the event 
stream represents a temporal line identifying the activities of 
the particular communications apparatus 22 during its life. 

45 Data mining could also be employed to identify relation- 
ships within the data to belter understand (he causes of 
inlermilten( problems. A further aspect related to the portal 
apparatus 310 could include providing developer access to 
software assets of one or more communications apparatuses 

50 22. The assets might include updated software, new APIs, 
technical notes and errata. Developers could browse pub- 
licly available lists that identify problems for use in arriving 
at solutions, as well as download new managers and inter- 
face header files for their internal development, llic portal 

55 apparatus 310 could also provide technical information for 
the development of communications apparatus software to 
globally spread and share useful information. 

The foregoing discussion of the invention has been pre- 
sented for purposes of illustration and description. Further, 

f>o the description is not intended to limit the invention to the 
form disclosed herein. Consequently, variations and modi- 
fications commensurate with the above teachings, within the 
skill and the knowledge of the relevant art, are within the 
scope of the present invention. 'Pie embodiments discussed 

65 hereinabove are further intended to explain the best mode 
known of practicing the inventions and to enable others 
skilled in the art to utilize (he inventions in such, or in other 
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embodiments and with the various modifications required by 
their particular applications or uses of the inventions. It is 
intended that the appended claims be construed to include 
alternative embodiments to the extent permitted by the prior 
art. 5 
What is claimed is: 

1. A method involving the transmission of information, 
comprising: 

providing a communications apparatus located in a 
vehicle and that includes: 10 
a plurality of common module managers including: a 
flow manager that manages data flow using 
components, a security manager that monitors con- 
nections outside said communications apparatus, a 
configuration manager that performs configuration is 
tasks including downloading applications and also 
including at least one of: a compression manager that 
compresses informalion and an encryption manager 
that encrypts information; and 
al least first, second, third and fourth disparate sub* 20 
system managers; 
providing at least first, second, third and fourth disparate 

subsystems; 
conducting a first operation including: 

sending a first message from said first disparate sub- 
system to said first disparate subsystem manager, 
said first message including identification informa- 
tion of said second disparate subsystem manager and 
a first request for first information involving said 
second disparate subsystem manager; 
receiving said first request by said first disparate sub- 
system manager; 
providing at least information related to said first 
request to said second disparate subsystem manager; 
accessing said first informalion from said second dis- 
parate subsystem in communication with said second 
disparate subsystem manager; 
transmitting said first information using said second 
disparate subsystem manager; 
wherein said first operation is conducted using al least two 
of said common module managers and in which each of 
said at least two common module managers are differ- 
ent from said compression manager; 
conducting a second operation including: 45 
sending a second message from said third disparate 
subsystem to said third disparate subsystem 
manager, said second message including a second 
request and identification information of said fourth 
disparate subsystem manager; 50 
receiving said second request by said third disparate 

subsystem manager; 
providing al least informalion related to said second 
request to said fourth disparate subsystem manager; 
responding to said second request by said fourth dis- 5S 
parale subsystem in communication with said fourth 
disparate subsystem manager; 
wherein said second operation is conducted using at least 
two of said common module managers and in which 
each of said at least two common module managers is ft o 
different from said encryption manager; 
wherein said first disparate subsystem is required to 
communicate with said first disparate subsystem man- 
ager related to said first message, said second disparate 
subsystem is required to communicate with said second o5 
disparate subsystem manager related to said first 
information, said third disparate subsystem is required 



to communicate with said third disparate subsystem 
manager related to said second message and said fourth 
disparate subsystem is required to communicate with 
said fourth disparate subsystem manager related to 
responding to said second request and each of said first, 
second, third and fourth disparate subsystem managers 
has a native interface that is different from the others to 
enable communications with said first, second, third 
and fourth disparate subsystems, respectively, and in 
which said common module managers arc located in 
the vehicle, said at least four disparate subsystem 
managers are located in the vehicle and said at least 
four disparate subsystems are located in the vehicle. 

2. A method, as claimed in claim 1, wherein: 

said step of sending said first message includes sending 
said first message from a site outside of the vehicle and 
said first disparate subsystem utilizes TCP/IP in com- 
municating over the Internet using wireless technology 
located in the vehicle. 

3. A method, as claimed in claim 1, wherein: 

said first message relates to a configuration packet includ- 
ing packet information related to a destination of said 
configuration packet from a source, a service related to 
said second disparate subsystem and said first informa- 
tion relates to data being obtained from said second 
disparate subsystem. 

4. A method, as claimed in claim 1, further including: 
receiving at least portions of said first request by said flow 

manager for managing performance of a first function 
related to said first information, 

5. A method, as claimed in claim 4, wherein: 

said managing performance step includes generating a 
child process that is involved with one of the following: 
encryption of said first informalion by said encryption 
manager and compression of said first information by 
said compression manager. 

6. A method, as claimed in claim 3, further including: 
receiving by said security manager said configuration 

packet and said security manager for use in determining 
access availability of the source associated with said 
configuration packet. 

7. A method, as claimed in claim 1, wherein: 

said step of receiving said first request includes checking 
for a request for service related to at least one of the 
following: encryption of information using said 
encryption manager, compression of information using 
said compression manager, and access to said commu- 
nications apparatus related to said first message using 
said security manager. 

8. A method, as claimed in claim 7, wherein: 

said checking step includes reading a configuration packet 
associated with said first message. 

9. A method, as claimed in claim 1, further including: 
producing a child process by said flow manager related to 

one of: encrypting said first information using said 
cncryplion manager and compressing said first infor- 
mation using said compression manager. 

10. A method, as claimed in claim 1, wherein: 

said producing step includes providing a metachild pro- 
cess that is involved in obtaining said first information 
from said second disparate subsystem and also obtain- 
ing second information from a fifth disparate sub- 
system. 

11. A method, as claimed in claim 10, wherein: 

said step of providing said metachild process includes 
creating said metachild process using said flow man- 
ager of said communications apparatus. 
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12. A method, as claimed in claim 1, further including: 
creating a first child process that is part of a communi- 
cations connection related to receiving said first infor- 
mation using said second disparate subsystem man- 
ager; S 

producing a second child process; and 

registering said first and second child processes using 

abase manager and dc-rcgistcring said first and second 

child processes. 

13. A method, as claimed in claim 1, further including: io 
registering said first and second disparate subsystems 

before said step of sending said first message. 

14. A method for providing information among a plurality 
of disparate subsystems using a plurality of managers and a 
common module, comprising: 15 

registering at least first, second and third disparate sub- 
system managers using a base manager of said common 
module, said first disparate subsystem manager being 
in communication with a first disparate subsystem, said 
second disparate subsystem manager being in eommu- 20 
nication with a second disparate subsystem and said 
third disparate subsystem manager being in communi- 
cation with a third disparate subsystem, said first, 
second and third disparate subsystems include: a wire- 
less communications device, transmission control 25 
protocol/Internet protocol (TCP/IP) and one of the 
following: a security manager that monitors external 
applications attempting to connect to at least one of 
said first, second and third disparate subsystem 
managers, a flow manager that enables communica- -JO 
tions involving at least one of said disparate subsystem 
managers, and a configuration manager that performs 
configuration tasks; 

obtaining first information from said first disparate sub- 
system using said first disparate subsystem manager, 35 
said obtaining step includes creating a first child com- 
ponent process using at least said second disparate 
subsystem manager and registering said first child 
component process using said base manager; 

sending said first information from said first disparate 40 
subsystem; 

transmitting second information using said third disparate 
subsystem manager to an external application; and 

creating a second child component process and registering 
said second child component process using said base 
manager; 

wherein each of said registering steps includes associating 
an identifier with each of said first, second and third 
disparate subsystem managers and associating an iden- so 
tiller with each of said first and second child component 
processes. 

15. A method, as claimed in claim 14, wherein: 

said obtaining step includes requesting said first informa- 
tion from said first disparate subsystem using a first 5S 
common communications protocol associated with said 
common module. 

16. A method, as claimed in claim 14, wherein: 

said sending step includes sending said first information 
continuously using a stream application programming 60 
interface (API) substantially independent of request 
and response messaging. 

17. A method, as claimed in claim 14, wherein: 

said second information includes said first information. 

18. A method, as claimed in claim 14, further including: b 5 
gathering information by a portal apparatus from a num- 
ber of vehicles associated with a fleet of vehicles 
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operated by a first entity, each of said number of 
vehicles having a communications apparatus and said 
portal apparatus communicating with each said com- 
munications apparatus using a first communications 
network and said portal apparatus being located 
remotely from each of said number of vehicles. 

19. A method, as claimed in claim 14, wherein: 

said second child component process is related to said 
second information. 

20. A system for providing communications in a vehicle, 
comprising: 

a plurality of disparate subsystems located in the vehicle 
and including a protocol stack, a global positioning 
system (GPS), voice recognition (VR) and at least one 
of: an intelligent transport system data bus (IDB) and a 
controller area network (CAN); and 
a communications apparatus operatively connected to 
each of said disparate subsystems that enables commu- 
nications between them, said communications appara- 
tus including: 

at least four disparate subsystem managers and each of 
said disparate subsystems being dedicated to one of 
said at least four disparate subsystem managers, 
wherein each of said disparate subsystems commu- 
nicates with its dedicated disparate subsystem man- 
ager and any communication involving a particular 
one of said disparate subsystems requires commu- 
nication with said disparate subsystem manager to 
which said particular one disparate subsystem is 
dedicated, at least some of said disparate subsystem 
managers provide messages to others of said dispar- 
ate subsystem managers, respond to messages from 
others of said disparate subsystem managers and 
create connections with others of said disparate 
subsystem managers; and 
at least four common module managers, wherein each 
of said at least four disparate subsystem managers 
uses a common communications protocol when 
communicating with each of said at least four com- 
mon module managers and each of said disparate 
subsystems communicates with its dedicated dispar- 
ate subsystem manager using a native interface that 
is different from native interfaces of the others of 
said at least four disparate subsystem managers, and 
in which each of said at least four disparate sub- 
system managers, each of said disparate subsystems 
and each of said at least four common module 
managers is located with the vehicle. 

21. A system, as claimed in claim 20, wherein: 
said disparate subsystems further include a plurality of the 

following: an analog-to-digilal converter in communi- 
cation with at least one hardware device, a standard 
serial bus in communication with a plurality of devices 
located in the vehicle and a universal serial bus (USB) 
in communication with computer hardware. 

22. A system, as claimed in claim 20, wherein: 
said at least four common module managers are part of a 

common module, including a processor core, that is 
involved with registering components, including said at 
least four disparate subsystem managers. 

23. A system, as claimed in claim 20, wherein: 
said common communications protocol includes at least 

one of the following: a stream mode of operation in 
which a stream applications programming interface 
(API) is used to send data continuously and a request/ 
response mode of operation using a bus applications 
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programming interface (API) in which information is 
transmitted by responding to a request from at least one 
of said disparate subsystem managers. 

24. A system, as claimed in claim 20, wherein: 

said communications apparatus includes a bridge mode of 5 
operation in which control of information transfer 
resides substantially externally of the vehicle and an 
application mode of operation in which control of 
information transfer resides substantially within the 
vehicle. 10 

25. A system, as claimed in claim 20, wherein: 

said at least four disparate subsystem managers includes 
a first disparate subsystem manager and a second 
disparate subsystem manager and in which a first child 
component process is created using at least one of said 15 
first and second disparate subsystem managers to estab- 
lish a connection between them. 

26. A system, as claimed in claim 20, wherein: 

said at least four common module managers include four 2Q 
of the following: a base manager used in registering 
said disparate subsystems, said at least four disparate 
subsystem managers and said a least four common 
module managers, a security manager for monitoring 
external applications attempting to connect to said 25 
communications apparatus, a link selection manager 
for providing an acceptable network link for transmit- 
ting and/or receiving information wirclcssly relative to 
the vehicle, a flow manager for enabling communica- 
tions involving three of said at least four disparate J(J 
subsystem managers, a compression manager for com- 
pressing data for transfer, and an encryption manager 
for encrypting data before transfer. 

27. A system, as claimed in claim 20, further including: 

a portal apparatus located remotely from the vehicle and 35 
in communication with said communications apparatus 
using wireless technology. 

28. A method for communicating with a numl>cr of 
vehicles, comprising: 

providing a plurality of communications apparatuses 40 
including a first communication apparatus and a second 
communications apparatus, each of the number of 
vehicles having a different one of said plurality of 
communications apparatuses; 

providing at least a first fleet management subsystem that 45 
manages at least a plurality of the number of vehicles 
in the fleet; 
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providing a portal apparatus located remotely from each 
of said fleet management subsystem and each of said 
plurality of communications apparatuses; 

providing a first communications network by which said 
portal apparatus communicates with each of said plu- 
rality of communications apparatuses and a second 
communications network by which said portal appara- 
tus communicates with said fleet management sub- 
system; 

maintaining information by said portal apparatus related 
to an identity of software being used by each of said 
communications apparatuses and in which said identity 
of software for said first communications apparatus is 
different from said identity of software for said second 
communications apparatus; 

updating software in each of said plurality of communi- 
cations apparatuses by said portal apparatus; 

obtaining vehicle operational data from each of said 
plurality of communications apparatuses by said portal 
apparatus; 

storing said vehicle operational data in memory of said 
portal apparatus; 

gathering diagnostic data from each of said communica- 
tions apparatuses by said portal apparatus; 

storing said diagnostic data in said memory of said portal 
apparatus; 

notifying said first fleet management subsystem by said 
portal apparatus of said identity of software being used 
by at least said first and second communications appa- 
ratuses; and 

sending at least some of said vehicle operational data and 
said diagnostic data to said fust fleet management 
subsystem by said portal apparatus. 

29. A method, as claimed in claim 28, wherein: 

at least said first communications network includes the 
Internet. 

30. A method, as claimed in claim 28, further including: 
providing a number of fleet management subsystems 

including said at least first fleet management subsystem 
and in which said at least first fleet management 
subsystem is notified related to said software being 
used by less than all of said plurality of communica- 
tions apparatuses. 

***** 
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